Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000206_owner-urn-ietf _Tue Nov 26 14:51:47 1996.msg

Internet Message Format | 1997-02-19 | 11KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA13107 for urn-ietf-out; Tue, 26 Nov 1996 14:51:47 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA13101 for <[e-mail]>; Tue, 26 Nov 1996 14:51:44 -0500
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA18308  (mail destined for [e-mail]); Tue, 26 Nov 96 14:51:40 -0500
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA22304; Tue, 26 Nov 1996 12:51:33 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 26 Nov 1996 13:00:09 -0700
To: Bob Briscoe <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Bob Briscoe (at least at 10:27 AM 11/26/96 +0000)

>[...] No-one seems to be able to get their head round the fact that [...]

I'm trying to understand your point, and am sorry that its taking
so much time. Lets try again.

>All I wanted was an *optional* persistence value to be possible,

Because of the limitations on DNS response sizes, there is a strong
incentive not to put in any fields that are not needed. If we can
agree that what you are asking for is necessary functionality not
achievable by other means, then we will modify the NAPTR proposal to
allow it. But I have not yet been convinced on that point. In fact,
during the course of preparing this reply, I am more firmly of the
view that the combination of DNS TTLs and the "Expires:" header of
the HTTP resolution protocol (and equivalant features in other
protocols) can achieve enough of what you are asking for that a
seperate "lifetime" field is not justified.

Let me try again to state what I think you are asking for and why. Then I
will explain what it won't achieve. Finally I will explain what it
will achieve beyond the combo of DNS TTL and "Expires:"-type info, and
why I think the additional benefit is not significant.

What I think you want:
=======================
A way to determine the minimum remaining lifetime of a resolver without
contacting that resolver to ask it. In other words, a new "lifetime"
field in the NAPTR record.

Why I think you want it:
========================
In an earlier message you indicated that one application of such a
capability would be to automate the maintenance of links in HTML-like
resources without continual polling, where a poll would probably be the
wasteful operation of fetching the resource then throwing it away. In
another message you said that this information will help in the migration
from one resolution protocol to another.

Why what you are asking for does not achieve at least some of
what you want:
===========================================================
Imagine that today (11/26/96) a customer signs a contract
with a Resolution Service Provider (RSP) for one year's worth of service.
You seem to be asking that the RSP be capable
of updating their NAPTR record to indicate that the HTTP resolver they
run will be available until at least 11/26/97. But of course,
new customers come along and sign new contracts, again for a year's
service. The NAPTR record could be continually updated to reflect that
the RSP is now contractually bound to provide the HTTP resolver for
a year after the most recent agreement with a customer. But why? It
does not mean that the the original customer's URNs will still be
resolvable there. Their contract was only for one year. Maybe they
have decided to contract with a different RSP that can offer the spiffy
new X2Y service.

This is why I think that a special "lifetime" field in the NAPTR
record does not achieve what you want from the "link maintenence" example.
If I write a paper and use a URN to link to someone else's resource, the
lifetime of the resolver does not necessarily tell me the lifetime of
their resolution info on that resolver. However, if I go ahead and ask
the resolver about that particular URN (assuming the approach in the HTTP
Conventions draft), the HTTP Expires: header can be used to provide
the detailed information on just how long one particular URN will
continue to be resolvable on one particular resolution server under
a particular resolution protocol. (This will be the minimum of the
time remaining on that customer's contract, the time until the
resolution service provider wants to scrap a particular resolution
protocol, and the time remaining on the resolution service provider's
contract with whoever they got their domain name from). When that
time has expired I can try to resolve the name again and see what
happens.


What it *would* achieve over existing capabilities and why I think
the additional benefit is not significant:
=================================================================
>I've been off-line with Ron Daniel who is happy that schemes such as HTTP
>which have expiry headers can get this information to you once you have
>resolved how to speak to HTTP.
>
>No-one seems to be able to get their head round the fact that such expiry
>times are meaningless if you don't know how long you will be able to resolve
>URNs which end up pointing to HTTP, but might point to another scheme later
>to keep them alive. I think the problem is that people just aren't thinking
>in terms of how much the world will change in the decades ahead. All I'm
>trying to propose is a way to avoid having to poll for broken resolution
>services in the future.

Let's look at a case where a resolution service provider (RSP) wants to
swap from HTTP to some other resolution protocol - Z39.50 for example.
We will also look at a couple of clients and how the swap affect them.

RSP:
----
When the RSP starts offering HTTP_based resolution, they might say
"OK, we will try this HTTP thing for 6 months as see how it goes".
Their N2L, N2C, ... scripts generate an Expires: header that clocks
down to that 6 month deadline. The NAPTR record for their HTTP-based
resolver has a TTL that is considerably shorter - 1 week perhaps -
to allow them to change the resolution services offered during the
initial experimental period with only the week's advance notice.

Client 1:
---------
Somewhere along the way, a smart link manager is given a URN and
starts to resolve it. It gets the Expires: header from the RSP's
HTTP-based resolver and caches the expiry data with the URN. Its
job as a "smart" link manager will be to recheck the availability of
the resource and flag an error when it is no longer resolvable. It
should do this in the least intrusive fashion possible.

RSP:
----
Sometime later, the RSP decides that they don't like the HTTP-based
approach and want to switch to a Z39.50-based approach. They will
wait until the 6-month period expires before killing off the HTTP
daemon, but in the meantime they bring up their Z39.50-based server and
install a NAPTR record to point to it. They also decide that they
want the NAPTR record for their HTTP server to disappear about a
week before the server itself is killed. So, they start clocking
down the TTL on the HTTP server's NAPTR record to that T=6mo-1week
deadline. At that time the HTTP daemon's NAPTR record will be removed.

Client 2:
---------
Before that T=6mo-1week deadline, a different user agent attempts to
resolve the URN and now encounters 2 terminal NAPTR records - one for
the HTTP resolver and one for the Z39.50 resolver. It picks which one to
talk to based on the protocols it knows how to speak, the services they
offer, etc. If it knows both resolution protocols, it MAY make the
decision based on the TTL of the NAPTR records. Once it has contacted
the resolver the client will know how long the resolver guarrantees to
provide resolution for that URN. As shown in the "contract" example
earlier, this can be a considerably shorter time than the lifetime of
the resolver.

Client 1:
---------
The 6 month expiry date comes along, and a random time later the
link manager wants to recheck the URN. It starts a new NAPTR resolution
which, some number of DNS probes later, gets it to the terminal NAPTR
records. There is now a new terminal NAPTR record for a Z39.50-based
resolver, but no HTTP-based record. If the client knows Z39.50
it can do something like N2Ls and get new expiry info. If not,
it can use the TTL as a provisional expiry date and do more frequent checks
of the DNS records in the hopes that a known resolution protocol will
be offered at some time in the future. When it is, a more accurate
expiry time can be obtained.



Your request for a resolver lifetime field would modify the scenario
above in two places.

In the Client 2 paragraph, in the case where the client could
speak more than one of the resolution protocols that were offered,
it could make the decision on which one to pursue based on the resolver
lifetime rather than the NAPTR TTL. However, as the "contract" example
shows, this does not guarantee that the resolver with the longer
minimum guaranteed lifetime actually will resolve that resource
longer than the other one. So, the difference here does not seem
all that significant.

The second place where the "lifetime" field would change the scenario
is in the last step where Client 1 does not know the new protocol.
Rather than marking the URN provisionally resolvable with the NAPTR
TTL as the time for the next check, it could mark it provisionally
resolvable with the Z39.50 resolver lifetime as the time for the next
check. The TTL is never longer than the resolver lifetime, so the TTL
is the safer choice although it will lead to more "polls". In this
case, however, a "poll" is fairly light weight - some DNS probes to
see if the terminal NAPTR for the unknown protocol still exits (in which
case we retain the provisionally resolvable status and check back later)
or if new NAPTRs exist that we can follow. These could be introduced
at any time so checking for them periodically is not a bad thing.
Here again, the benefit from the new field does not seem so clear-cut that
I'm not convinced it is necessary.


I'm willing to be convinced of the necessity for such a field. However,
since it requires extra space in the records and changes to running
code you have to make a good case for it. If you can show me where the
combination of DNS TTLs and resolution-specific Expiry info does not
provide enough info to handle an important case, and the new field would,
I'll change the spec.

Regards,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"